<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-type" content="text/html;charset=utf-8">
<title>外文翻译原文</title>
<style type="text/css" media="print">
article.paging{page-break-before:always;}
</style>
<style>
	h1{text-align:center;}
	
	body{font-family:"Times New Roman";line-height: 20pt;}
</style>
</head>

<body>
	<article>
		<h1>Avoiding Memory Leaks</h1>
		<div id="jd-content">
			<div class="jd-descr" itemprop="articleBody">
				<p>
					Android applications are, at least on the T-Mobile G1, limited to
					16 MB of heap. It's both a lot of memory for a phone and yet very
					little for what some developers want to achieve. Even if you do not
					plan on using all of this memory, you should use as little as
					possible to let other applications run without getting them killed.
					The more applications Android can keep in memory, the faster it
					will be for the user to switch between his apps. As part of my job,
					I ran into memory leaks issues in Android applications and they are
					most of the time due to the same mistake: keeping a long-lived
					reference to a
					<code>
						<a href="../../reference/android/content/Context.html">Context</a>
					</code>
					.
				</p>

				<p>
					On Android, a
					<code>Context</code>
					is used for many operations but mostly to load and access
					resources. This is why all the widgets receive a
					<code>Context</code>
					parameter in their constructor. In a regular Android application,
					you usually have two kinds of
					<code>Context</code>
					,
					<code>
						<a href="../../reference/android/app/Activity.html">Activity</a>
					</code>
					and
					<code>
						<a href="../../reference/android/app/Application.html">Application</a>
					</code>
					. It's usually the first one that the developer passes to classes
					and methods that need a
					<code>Context</code>
					:
				</p>

				<pre class="prettyprint">
&#64;Override
protected void onCreate(Bundle state) {
  super.onCreate(state);
  
  TextView label = new TextView(this);
  label.setText("Leaks are bad");
  
  setContentView(label);
}
</pre>

				<p>
					This means that views have a reference to the entire activity and
					therefore to anything your activity is holding onto; usually the
					entire View hierarchy and all its resources. Therefore, if you leak
					the
					<code>Context</code>
					("leak" meaning you keep a reference to it thus preventing the GC
					from collecting it), you leak a lot of memory. Leaking an entire
					activity can be really easy if you're not careful.
				</p>

				<p>When the screen orientation changes the system will, by
					default, destroy the current activity and create a new one while
					preserving its state. In doing so, Android will reload the
					application's UI from the resources. Now imagine you wrote an
					application with a large bitmap that you don't want to load on
					every rotation. The easiest way to keep it around and not having to
					reload it on every rotation is to keep in a static field:</p>

				<pre class="prettyprint">
private static Drawable sBackground;
  
&#64;Override
protected void onCreate(Bundle state) {
  super.onCreate(state);
  
  TextView label = new TextView(this);
  label.setText("Leaks are bad");
  
  if (sBackground == null) {
    sBackground = getDrawable(R.drawable.large_bitmap);
  }
  label.setBackgroundDrawable(sBackground);
  
  setContentView(label);
}
</pre>

				<p>
					This code is very fast and also very wrong; it leaks the first
					activity created upon the first screen orientation change. When a
					<code>
						<a href="../../reference/android/graphics/drawable/Drawable.html">Drawable</a>
					</code>
					is attached to a view, the view is set as a
					<code>
						<a
							href="../../reference/android/graphics/drawable/Drawable.html#setCallback(android.graphics.drawable.Drawable.Callback)">callback</a>
					</code>
					on the drawable. In the code snippet above, this means the drawable
					has a reference to the
					<code>TextView</code>
					which itself has a reference to the activity (the
					<code>Context</code>
					) which in turns has references to pretty much anything (depending
					on your code.)
				</p>

				<p>
					This example is one of the simplest cases of leaking the
					<code>Context</code>
					and you can see how we worked around it in the <a
						href="http://android.git.kernel.org/?p=platform/packages/apps/Launcher.git;a=blob;f=src/com/android/launcher/LauncherModel.java;h=0ef2a806b767142b28b2ff3b37f21f4ca16c355d;hb=cupcake">Home
						screen's source code</a> (look for the
					<code>unbindDrawables()</code>
					method) by setting the stored drawables' callbacks to null when the
					activity is destroyed. Interestingly enough, there are cases where
					you can create a chain of leaked contexts, and they are bad. They
					make you run out of memory rather quickly.
				</p>

				<p>
					There are two easy ways to avoid context-related memory leaks. The
					most obvious one is to avoid escaping the context outside of its
					own scope. The example above showed the case of a static reference
					but inner classes and their implicit reference to the outer class
					can be equally dangerous. The second solution is to use the
					<code>Application</code>
					context. This context will live as long as your application is
					alive and does not depend on the activities life cycle. If you plan
					on keeping long-lived objects that need a context, remember the
					application object. You can obtain it easily by calling
					<code>
						<a
							href="../../reference/android/content/Context.html#getApplicationContext()">Context.getApplicationContext()</a>
					</code>
					or
					<code>
						<a
							href="../../reference/android/app/Activity.html#getApplication()">Activity.getApplication()</a>
					</code>
					.
				</p>

				<p>In summary, to avoid context-related memory leaks, remember
					the following:</p>
				<ul>
					<li>Do not keep long-lived references to a context-activity (a
						reference to an activity should have the same life cycle as the
						activity itself)</li>
					<li>Try using the context-application instead of a
						context-activity</li>
					<li>Avoid non-static inner classes in an activity if you don't
						control their life cycle, use a static inner class and make a weak
						reference to the activity inside. The solution to this issue is to
						use a static inner class with a <code>
							<a href="../../reference/java/lang/ref/WeakReference.html">WeakReference</a>
						</code> to the outer class, as done in <a
						href="http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=core/java/android/view/ViewRoot.java;h=9d7a124cb01ab94bf53e34f6e5e8a07f81e2423c;hb=master">ViewRoot</a>
						and its W inner class for instance
					</li>
					<li>A garbage collector is not an insurance against memory
						leaks</li>
				</ul>

			</div>


		</div>
		<!-- end jd-content -->
	</article><!-- end of article Avoiding Memory Leaks -->
	<article  class="paging">
		<h1>Multitasking the Android Way</h1>
		<div id="jd-content">
    <div class="jd-descr" itemprop="articleBody">

<p>Android is fairly unique in the ways it allows multiple applications to run at the same time.  Developers coming from a different platform may find the way it operates surprising.  Understanding its behavior is important for designing applications that will work well and integrate seamlessly with the rest of the Android platform.  This article covers the reasons for Android's multitasking design, its impact on how applications work, and how you can best take advantage of Android's unique features.</p>
<h3>Design considerations</h3>
<p>Mobile devices have technical limitations and user experience requirements not present in desktop or web systems.  Here are the four key constraints we were working under as we designed Android's multitasking:</p>
<ul>
  <li>
    <p>We did not want to require that users close applications when "done" with them.  Such a usage pattern does not work well in a mobile environment, where usage tends to involve repeated brief contact with a wide variety of applications throughout the day.</p>
  </li>
  <li>
    <p>Mobile devices don't have the luxury of swap space, so have fairly hard limits on memory use.  Robert Love has <a href="http://blog.rlove.org/2010/04/why-ipad-and-iphone-dont-support.html">a very good article</a> covering the topic.</p>
  </li>
  <li>
    <p>Application switching on a mobile device is extremely critical; we target significantly less than 1 second to launch a new application.  This is especially important when the user is switching between a few applications, such as switching to look at a new SMS message while watching a video, and then returning to that video.  A noticeable wait in such situations will quickly make users hate you.</p>
  </li>
  <li>
    <p>The available APIs must be sufficient for writing the built-in Google applications, as part of our "all applications are created equal" philosophy.  This means background music playback, data syncing, GPS navigation, and application downloading must be implemented with the same APIs that are available to third party developers.</p>
  </li>
</ul>
<p>The first two requirements highlight an interesting conflict.  We don't want users to worry about closing their apps, but rather make it appear that all of the applications are always running.  At the same time, mobile devices have hard limits on memory use, so that a system will degrade or even start failing very quickly as it needs more RAM than is available; a desktop computer, with swap, in contrast will simply start slowing down as it needs to page RAM to its swap space.  These competing constraints were a key motivation for Android's design.</p>
<h3>When does an application "stop"?</h3>
<p>A common misunderstanding about Android multitasking is the difference between a process and an application.  In Android these are not tightly coupled entities: applications may seem present to the user without an actual process currently running the app; multiple applications may share processes, or one application may make use of multiple processes depending on its needs; the process(es) of an application may be kept around by Android even when that application is not actively doing something.</p>
<p>The fact that you can see an application's process "running" does not mean the application is running or doing anything.  It may simply be there because Android needed it at some point, and has decided that it would be best to keep it around in case it needs it again.  Likewise, you may leave an application for a little bit and return to it from where you left off, and during that time Android may have needed to get rid of the process for other things.</p>
<p>A key to how Android handles applications in this way is that processes don't shut down cleanly.  When the user leaves an application, its process is kept around in the background, allowing it to continue working (for example downloading web pages) if needed, and come immediately to the foreground if the user returns to it.  If a device never runs out of memory, then Android will keep all of these processes around, truly leaving all applications "running" all of the time.</p>
<p>Of course, there is a limited amount of memory, and to accommodate this Android must decide when to get rid of processes that are not needed.  This leads to Android's <a href="../../guide/topics/fundamentals.html#proclife">process lifecycle</a>, the rules it uses to decide how important each process is and thus the next one that should be dropped.  These rules are based on both how important a process is for the user's current experience, as well as how long it has been since the process was last needed by the user.</p>
<p>Once Android determines that it needs to remove a process, it does this brutally, simply force-killing it.  The kernel can then immediately reclaim all resources needed by the process, without relying on that application being well written and responsive to a polite request to exit.  Allowing the kernel to immediately reclaim application resources makes it a lot easier to avoid serious out of memory situations.</p>
<p>If a user later returns to an application that's been killed, Android needs a way to re-launch it in the same state as it was last seen, to preserve the "all applications are running all of the time" experience.  This is done by keeping track of the parts of the application the user is aware of (the Activities), and re-starting them with information about the last state they were seen in.  This last state is generated each time the user leaves that part of the application, not when it is killed, so that the kernel can later freely kill it without depending on the application to respond correctly at that point.</p>
<p>In some ways, Android's process management can be seen as a form of swap space: application processes represent a certain amount of in-use memory; when memory is low, some processes can be killed (swapped out); when those processes are needed again, they can be re-started from their last saved state (swapped in).</p>
<h3>Explicitly running in the background</h3>
<p>So far, we have a way for applications to implicitly do work in the background, as long as the process doesn't get killed by Android as part of its regular memory management.  This is fine for things like loading web pages in the background, but what about features with harder requirements?  Background music playback, data synchronization, location tracking, alarm clocks, etc.</p>
<p/>
<p>For these tasks, the application needs a way to tell Android "I would explicitly like to run at this point."  There are two main facilities available to applications for this, represented by two kinds of components they can publish in their manifest: <span style="font-style:italic;">broadcast receivers</span> and <span style="font-style:italic;">services</span>.</p>
<h4>Broadcast Receivers</h4>
<p>A BroadcastReceiver allows an application to run, for a brief amount of time, in the background as a result of something else happening.  It can be used in many ways to build higher-level facilities: for example the AlarmManager allows an application to have a broadcast sent at a certain time in the future, and the LocationManager can send a broadcast when it detects interesting changes in location.  Because information about the receiver is part of an application's manifest, Android can find and launch the application even if it isn't running; of course if it already has its process available in the background, the broadcast can very efficiently be directly dispatched to it.</p>
<p>When handling a broadcast, the application is given a fixed set of time (currently 10 seconds) in which to do its work.  If it doesn't complete in that time, the application is considered to be misbehaving, and its process immediately tossed into the background state to be killed for memory if needed.</p>
<p>Broadcast receivers are great for doing small pieces of work in response to an external stimulus, such as posting a notification to the user after being sent a new GPS location report.  They are very lightweight, since the application's process only needs to be around while actively receiving the broadcast.  Because they are active for a deterministic amount of time, fairly strong guarantees can be made about not killing their process while running.  However they are not appropriate for anything of indeterminate length, such as networking.</p>
<h4>Services</h4>
<p>A Service allows an application to implement longer-running background operations.  There are actually a lot of other functions that services provide, but for the discussion here their fundamental purpose is for an application to say "hey I would like to continue running even while in the background, until I say I am done."  An application controls when its service runs by explicitly starting and stopping the service.</p>
<p>While services do provide a rich client-server model, its use is optional.  Upon starting an application's services, Android simply instantiates the component in the application's process to provide its context.  How it is used after that is up to the application: it can put all of the needed code inside of the service itself without interacting with other parts of the application, make calls on other singleton objects shared with other parts of the app, directly retrieve the Service instance from elsewhere if needed, or run it in another process and do a full-blown RPC protocol if that is desired.</p>
<p>Process management for services is different than broadcast receivers, because an unbounded number of services can ask to be running for an unknown amount of time.  There may not be enough RAM to have all of the requesting services run, so as a result no strong guarantees are made about being able to keep them running.</p>
<p>If there is too little RAM, processes hosting services will be immediately killed like background processes are.  However, if appropriate, Android will remember that these services wish to remain running, and restart their process at a later time when more RAM is available.  For example, if the user goes to a web page that requires large amounts of RAM, Android may kill background service processes like sync until the browser's memory needs go down.</p>
<p>Services can further negotiate this behavior by requesting they be considered "foreground."  This places the service in a "please don't kill" state, but requires that it include a notification to the user about it actively running.  This is useful for services such as background music playback or car navigation, which the user is actively aware of; when you're playing music and using the browser, you can always see the music-playing glyph in the status bar.  Android won't try to kill these services, but as a trade-off, ensures the user knows about them and is able to explicitly stop them when desired.</p>
<h3>The value of generic components</h3>
<p>Android's generic broadcast receiver and service components allow developers to create a wide variety of efficient background operations, including things that were never originally considered.  In Android 1.0 they were used to implement nearly all of the background behavior that the built-in and proprietary Google apps provided:</p>
<ul>
  <li>
    Music playback runs in a service to allow it to continue operating after the user leaves the music application.
  </li>
  <li>
    The alarm clock schedules a broadcast receiver with the alarm manager, to go off at the next set alarm time.
  </li>
  <li>
    The calendar application likewise schedules an alarm to display or update its notification at the appropriate time for the next calendar event.
  </li>
  <li>
    Background file download is implemented a service that runs when there are any downloads to process.
  </li>
  <li>
    The e-mail application schedules an alarm to wake up a service at regular intervals that looks for and retrieves any new mail.
  </li>
  <li>
    The Google applications maintain a service to receive push notifications from the network; it in turn sends broadcasts to individual apps when it is told that they need to do things like synchronize contacts.</p>
  </li>
</ul>
<p>As the platform has evolved, these same basic components have been used to implement many of the major new developer features:
<ul>
  <li>
    Input methods are implemented by developers as a Service component that Android manages and works with to display as the current IME.
  </li>
  <li>
    Application widgets are broadcast receivers that Android sends broadcasts to when it needs to interact with them.  This allows app widgets to be quite lightweight, by not needing their application's process remain running.
  </li>
  <li>
    Accessibility features are implemented as services that Android keeps running while in use and sends appropriate information to about user interactions.
  </li>
  <li>
    Sync adapters introduced in Android 2.0 are services that are run in the background when a particular data sync needs to be performed.
  </li>
  <li>
    Live wallpapers are a service started by Android when selected by the user.
  </li>
</ul>

    </div>
  </div> <!-- end jd-content -->
	</article>
	<!--  end of article Multitasking the Android Way -->
		
	<article class="paging">
		<h1>How Android Draws Views</h1>
<div id="jd-content">
    <div class="jd-descr" itemprop="articleBody">
    <p>When an Activity receives focus, it will be requested to draw its layout.
The Android framework will handle the procedure for drawing, but the Activity must provide
the root node of its layout hierarchy.</p>

<p>Drawing begins with the root node of the layout. It is requested to measure and 
draw the layout tree. Drawing is handled by walking the tree and rendering each View that
   intersects the invalid region. In turn, each View group is responsible for requesting
each of its children to be drawn (with the <code><code><a href="../../../reference/android/view/View.html#draw(android.graphics.Canvas)">draw()</a></code></code> method) 
and each View is responsible for drawing itself.
 Because the tree is traversed in-order,
   this means that parents will be drawn before (i.e., behind) their children, with
   siblings drawn in the order they appear in the tree.
   </p>


<p>
   Drawing the layout is a two pass process: a measure pass and a layout pass. The measuring
   pass is implemented in <code><code><a href="../../../reference/android/view/View.html#measure(int, int)">measure(int, int)</a></code></code> and is a top-down traversal
   of the View tree. Each View pushes dimension specifications down the tree
   during the recursion. At the end of the measure pass, every View has stored
   its measurements. The second pass happens in
   <code><code><a href="../../../reference/android/view/View.html#layout(int, int, int, int)">layout(int, int, int, int)</a></code></code> and is also top-down. During
   this pass each parent is responsible for positioning all of its children
   using the sizes computed in the measure pass.
   </p>
   
   <p>
   When a View's <code>measure()</code> method returns, its <code><code><a href="../../../reference/android/view/View.html#getMeasuredWidth()">getMeasuredWidth()</a></code></code> and
   <code><code><a href="../../../reference/android/view/View.html#getMeasuredHeight()">getMeasuredHeight()</a></code></code> values must be set, along with those for all of
   that View's descendants. A View's measured width and measured height values
   must respect the constraints imposed by the View's parents. This guarantees
   that at the end of the measure pass, all parents accept all of their
   children's measurements. A parent View may call <code>measure()</code> more than once on
   its children. For example, the parent may measure each child once with
   unspecified dimensions to find out how big they want to be, then call
   <code>measure()</code> on them again with actual numbers if the sum of all the children's
   unconstrained sizes is too big or too small (i.e., if the children don't agree among themselves
  as to how much space they each get, the parent will intervene and set the rules on the second pass).
   </p>
   


   <p>
   The measure pass uses two classes to communicate dimensions. The
   <code><a href="../../../reference/android/view/View.MeasureSpec.html">View.MeasureSpec</a></code> class is used by Views to tell their parents how they
   want to be measured and positioned. The base LayoutParams class just
   describes how big the View wants to be for both width and height. For each
   dimension, it can specify one of:</p>
   <ul>
    <li> an exact number
    <li><var>FILL_PARENT</var>, which means the View wants to be as big as its parent
    (minus padding)</li>
    <li><var>WRAP_CONTENT</var>, which means that the View wants to be just big enough to
    enclose its content (plus padding).</li>
   </ul>
  <p>There are subclasses of LayoutParams for different subclasses of ViewGroup.
   For example, RelativeLayout has its own subclass of LayoutParams, which includes
   the ability to center child Views horizontally and vertically.
   </p>
   
   <p>
   MeasureSpecs are used to push requirements down the tree from parent to
   child. A MeasureSpec can be in one of three modes:</p>
   <ul>
    <li><var>UNSPECIFIED</var>: This is used by a parent to determine the desired dimension
    of a child View. For example, a LinearLayout may call <code>measure()</code> on its child
    with the height set to <var>UNSPECIFIED</var> and a width of <var>EXACTLY</var> 240 to find out how
    tall the child View wants to be given a width of 240 pixels.</li>
    <li><var>EXACTLY</var>: This is used by the parent to impose an exact size on the
    child. The child must use this size, and guarantee that all of its
    descendants will fit within this size.</li>
    <li><var>AT_MOST</var>: This is used by the parent to impose a maximum size on the
    child. The child must guarantee that it and all of its descendants will fit
    within this size.</li>
   </ul>
    </div>


    

  </div> <!-- end jd-content -->

	</article><!-- end How Android Draws Views -->
	<article class="paging">
		<h1>Tasks and Back Stack</h1>

  <div id="jd-content">
    <div class="jd-descr" itemprop="articleBody">
		<ul>
  <li>All activities belong to a task</li>
  <li>A task contains a collection of activities in the order in which the user interacts with
them</li>
  <li>Tasks can move to the background and retain the state of each activity in order for users
to perform other tasks without losing their work</li>
</ul>

<p>An application usually contains multiple <a
href="../../../guide/topics/fundamentals/activities.html">activities</a>. Each activity
should be designed around a specific kind of action the user can perform and can start other
activities. For example, an email application might have one activity to show a list of new email.
When the user selects an email, a new activity opens to view that email.</p>

<p>An activity can even start activities that exist in other applications on the device. For
example, if your application wants to send an email, you can define an intent to perform a "send"
action and include some data, such as an email address and a message. An activity from another
application that declares itself to handle this kind of intent then opens. In this case, the intent
is to send an email, so an email application's "compose" activity starts (if multiple activities
support the same intent, then the system lets the user select which one to use). When the email is
sent, your activity resumes and it seems as if the email activity was part of your application. Even
though the activities may be from different applications, Android maintains this seamless user
experience by keeping both activities in the same <em>task</em>.</p>

<p>A task is a collection of activities that users interact with
when performing a certain job. The activities are arranged in a stack (the "back stack"), in the
order in which each activity is opened.</p>



<p>The device Home screen is the starting place for most tasks. When the user touches an icon in the
application
launcher (or a shortcut on the Home screen), that application's task comes to the foreground. If no
task exists for the application (the application has not been used recently), then a new task
is created and the "main" activity for that application opens as the root activity in the stack.</p>

<p>When the current activity starts another, the new activity is pushed on the top of the stack and
takes focus. The previous activity remains in the stack, but is stopped. When an activity
stops, the system retains the current state of its user interface. When the user presses the
<em>Back</em>
button, the current activity is popped from the top of the stack (the activity is destroyed) and the
previous activity resumes (the previous state of its UI is restored). Activities in the stack are
never rearranged, only pushed and popped from the stack&mdash;pushed onto the stack when started by
the current activity and popped off when the user leaves it using the <em>Back</em> button. As such,
the back
stack operates as a "last in, first out" object structure. </p>




<p>If the user continues to press <em>Back</em>, then each activity in the stack is popped off to
reveal the
previous one, until the user returns to the Home screen (or to whichever activity was running when
the task began). When all activities are removed from the stack, the task no longer exists.</p>



<p>A task is a cohesive unit that can move to the "background" when users begin a new task or go
to the Home screen, via the <em>Home</em> button. While in the background, all the activities in the
task are
stopped, but the back stack for the task remains intact&mdash;the task has simply lost focus while
another task takes place, as shown in figure 2. A task can then return to the "foreground" so users
can pick up where they left off. Suppose, for example, that the current task (Task A) has three
activities in its stack&mdash;two under the current activity. The user presses the <em>Home</em>
button, then
starts a new application from the application launcher. When the Home screen appears, Task A goes
into the background. When the new application starts, the system starts a task for that application
(Task B) with its own stack of activities. After interacting with
that application, the user returns Home again and selects the application that originally
started Task A. Now, Task A comes to the
foreground&mdash;all three activities in its stack are intact and the activity at the top of the
stack resumes. At
this point, the user can also switch back to Task B by going Home and selecting the application icon
that started that task (or by touching and holding the <em>Home</em> button to reveal recent tasks
and selecting
one). This is an example of multitasking on Android.</p>

<p class="note"><strong>Note:</strong> Multiple tasks can be held in the background at once.
However, if the user is running many background tasks at the same time, the system might begin
destroying background activities in order to recover memory, causing the activity states to be lost.
See the following section about <a href="#ActivityState">Activity state</a>.</p>

<p>Because the activities in the back stack are never rearranged, if your application allows
users to start a particular activity from more than one activity, a new instance of
that activity is created and pushed onto the stack (rather than bringing any previous instance of
the activity to the top). As such, one activity in your application might be instantiated multiple
times (even from different tasks), as shown in figure 3. As such, if the user navigates backward
using the <em>Back</em> button, each instance of the activity is revealed in the order they were
opened (each
with their own UI state). However, you can modify this behavior if you do not want an activity to be
instantiated more than once. How to do so is discussed in the later section about <a
href="#ManagingTasks">Managing Tasks</a>.</p>


<p>To summarize the default behavior for activities and tasks:</p>

<ul>
  <li>When Activity A starts Activity B, Activity A is stopped, but the system retains its state
(such as scroll position and text entered into forms).
If the user presses the <em>Back</em> button while in Activity B, Activity A resumes with its state
restored.</li>
  <li>When the user leaves a task by pressing the <em>Home</em> button, the current activity is
stopped and
its task goes into the background. The system retains the state of every activity in the task. If
the user later resumes the task by selecting the launcher icon that began the task, the task comes
to the foreground and resumes the activity at the top of the stack.</li>
  <li>If the user presses the <em>Back</em> button, the current activity is popped from the stack
and
destroyed. The previous activity in the stack is resumed. When an activity is destroyed, the system
<em>does not</em> retain the activity's state.</li>
  <li>Activities can be instantiated multiple times, even from other tasks.</li>
</ul>


<div class="design-announce">
<p><strong>Navigation Design</strong></p>
  <p>For more about how app navigation works on Android, read Android Design's <a
href="../../../design/patterns/navigation.html">Navigation</a> guide.</p>
</div>


<h2 id="ActivityState">Saving Activity State</h2>

<p>As discussed above, the system's default behavior preserves the state of an activity when it is
stopped. This way, when users navigate back to a previous activity, its user interface appears
the way they left it. However, you can&mdash;and <strong>should</strong>&mdash;proactively retain
the state of your activities using callback methods, in case the activity is destroyed and must
be recreated.</p>

<p>When the system stops one of your activities (such as when a new activity starts or the task
moves to the background), the system might destroy that activity completely if it needs to recover
system memory. When this happens, information about the activity state is lost. If this happens, the
system still
knows that the activity has a place in the back stack, but when the activity is brought to the
top of the stack the system must recreate it (rather than resume it). In order to
avoid losing the user's work, you should proactively retain it by implementing the <code><a href="../../../reference/android/app/Activity.html#onSaveInstanceState(android.os.Bundle)">onSaveInstanceState()</a></code> callback
methods in your activity.</p>

<p>For more information about how to save your activity state, see the <a
href="../../../guide/topics/fundamentals/activities.html#SavingActivityState">Activities</a>
document.</p>



<h2 id="ManagingTasks">Managing Tasks</h2>

<p>The way Android manages tasks and the back stack, as described above&mdash;by placing all
activities started in succession in the same task and in a "last in, first out" stack&mdash;works
great for most applications and you shouldn't have to worry about how your activities are associated
with tasks or how they exist in the back stack. However, you might decide that you want to interrupt
the normal behavior. Perhaps you want an activity in your application to begin a new task when it is
started (instead of being placed within the current task); or, when you start an activity, you want
to bring forward an existing instance of it (instead of creating a new
instance on top of the back stack); or, you want your back stack to be cleared of all
activities except for the root activity when the user leaves the task.</p>

<p>You can do these things and more, with attributes in the
<a href="../../../guide/topics/manifest/activity-element.html"><code>&lt;activity&gt;</code></a> manifest element and with flags in the intent that you pass to <code><a href="../../../reference/android/app/Activity.html#startActivity(android.content.Intent)">startActivity()</a></code>.</p>

<p>In this regard, the the principal <a
href="../../../guide/topics/manifest/activity-element.html"><code>&lt;activity&gt;</code></a>
attributes you can use are:</p>

<ul class="nolist">
  <li><a href="../../../guide/topics/manifest/activity-element.html#aff"><code>taskAffinity</code></a></li>
  <li><a href="../../../guide/topics/manifest/activity-element.html#lmode"><code>launchMode</code></a></li>
  <li><a href="../../../guide/topics/manifest/activity-element.html#reparent"><code>allowTaskReparenting</code></a></li>
  <li><a href="../../../guide/topics/manifest/activity-element.html#clear"><code>clearTaskOnLaunch</code></a></li>
  <li><a href="../../../guide/topics/manifest/activity-element.html#always"><code>alwaysRetainTaskState</code></a></li>
  <li><a href="../../../guide/topics/manifest/activity-element.html#finish"><code>finishOnTaskLaunch</code></a></li>
</ul>

<p>And the principal intent flags you can use are:</p>

<ul class="nolist">
  <li><code><a href="../../../reference/android/content/Intent.html#FLAG_ACTIVITY_NEW_TASK">FLAG_ACTIVITY_NEW_TASK</a></code></li>
  <li><code><a href="../../../reference/android/content/Intent.html#FLAG_ACTIVITY_CLEAR_TOP">FLAG_ACTIVITY_CLEAR_TOP</a></code></li>
  <li><code><a href="../../../reference/android/content/Intent.html#FLAG_ACTIVITY_SINGLE_TOP">FLAG_ACTIVITY_SINGLE_TOP</a></code></li>
</ul>

<p>In the following sections, you'll see how you can use these manifest attributes and intent
flags to define how activities are associated with tasks and how the behave in the back stack.</p>


<p class="caution"><strong>Caution:</strong> Most applications should not interrupt the default
behavior for activities and tasks. If you determine that it's necessary for your activity to modify
the default behaviors, use caution and be sure to test the usability of the activity during
launch and when navigating back to it from other activities and tasks with the <em>Back</em> button.
Be sure 
to test for navigation behaviors that might conflict with the user's expected behavior.</p>


<h3 id="TaskLaunchModes">Defining launch modes</h3>

<p>Launch modes allow you to define how a new instance of an activity is associated with the
current task. You can define different launch modes in two ways:</p>
<ul class="nolist">
  <li><a href="#ManifestForTasks">Using the manifest file</a>
    <p>When you declare an activity in your manifest file, you can specify how the activity
should associate with tasks when it starts.</li>
  <li><a href="#IntentFlagsForTasks">Using Intent flags</a>
    <p>When you call <code><a href="../../../reference/android/app/Activity.html#startActivity(android.content.Intent)">startActivity()</a></code>,
you can include a flag in the <code><a href="../../../reference/android/content/Intent.html">Intent</a></code> that declares how (or
whether) the new activity should associate with the current task.</p></li>
</ul>

<p>As such, if Activity A starts Activity B, Activity B can define in its manifest how it
should associate with the current task (if at all) and Activity A can also request how Activity
B should associate with current task. If both activities define how Activity B
should associate with a task, then Activity A's request (as defined in the intent) is honored
over Activity B's request (as defined in its manifest).</p>

<p class="note"><strong>Note:</strong> Some launch modes available for the manifest file
are not available as flags for an intent and, likewise, some launch modes available as flags
for an intent cannot be defined in the manifest.</p>


<h4 id="ManifestForTasks">Using the manifest file</h4>

<p>When declaring an activity in your manifest file, you can specify how the activity should
associate with a task using the <a
href="../../../guide/topics/manifest/activity-element.html"><code>&lt;activity&gt;</code></a>
element's <a href="../../../guide/topics/manifest/activity-element.html#lmode"><code>launchMode</code></a> attribute.</p>

<p>The <a href="../../../guide/topics/manifest/activity-element.html#lmode"><code>launchMode</code></a> attribute specifies an instruction on how the activity should be launched into a
task. There are four different launch modes you can assign to the
<code><a href="../../../guide/topics/manifest/activity-element.html#lmode">launchMode</a></code>
attribute:</p>

<dl>
<dt><code>"standard"</code> (the default mode)</dt>
  <dd>Default. The system creates a new instance of the activity in the task from
which it was started and routes the intent to it. The activity can be instantiated multiple times,
each instance can belong to different tasks, and one task can have multiple instances.</dd>
<dt><code>"singleTop"</code></dt>
  <dd>If an instance of the activity already exists at the top of the current task, the system
routes the intent to that instance through a call to its <code><a href="../../../reference/android/app/Activity.html#onNewIntent(android.content.Intent)">onNewIntent()</a></code> method, rather than creating a new instance of the
activity. The activity can be instantiated multiple times, each instance can
belong to different tasks, and one task can have multiple instances (but only if the the
activity at the top of the back stack is <em>not</em> an existing instance of the activity).
  <p>For example, suppose a task's back stack consists of root activity A with activities B, C,
and D on top (the stack is A-B-C-D; D is on top). An intent arrives for an activity of type D.
If D has the default <code>"standard"</code> launch mode, a new instance of the class is launched and the
stack becomes A-B-C-D-D. However, if D's launch mode is <code>"singleTop"</code>, the existing instance
of D receives the intent through <code><a href="../../../reference/android/app/Activity.html#onNewIntent(android.content.Intent)">onNewIntent()</a></code>, because it's at the top of the stack&mdash;the
stack remains A-B-C-D. However, if an intent arrives for an activity of type B, then a new
instance of B is added to the stack, even if its launch mode is <code>"singleTop"</code>.</p>
  <p class="note"><strong>Note:</strong> When a new instance of an activity is created,
the user can press the <em>Back</em> button to return to the previous activity. But when an existing
instance of
an activity handles a new intent, the user cannot press the <em>Back</em> button to return to the
state of
the activity before the new intent arrived in <code><a href="../../../reference/android/app/Activity.html#onNewIntent(android.content.Intent)">onNewIntent()</a></code>.</p>
</dd>

<dt><code>"singleTask"</code></dt>
  <dd>The system creates a new task and instantiates the activity at the root of the new task.
However, if an instance of the activity already exists in a separate task, the system routes the
intent to the existing instance through a call to its <code><a href="../../../reference/android/app/Activity.html#onNewIntent(android.content.Intent)">onNewIntent()</a></code> method, rather than creating a new instance. Only
one instance of the activity can exist at a time.
  <p class="note"><strong>Note:</strong> Although the activity starts in a new task, the
<em>Back</em> button still returns the user to the previous activity.</p></dd>
<dt><code>"singleInstance"</code>.</dt>
  <dd>Same as <code>"singleTask"</code>, except that the system doesn't launch any other activities into
the task holding the instance. The activity is always the single and only member of its task;
any activities started by this one open in a separate task.</dd>
</dl>


<p>As another example, the Android Browser application declares that the web browser activity should
always open in its own task&mdash;by specifying the <code>singleTask</code> launch mode in the <a
href="../../../guide/topics/manifest/activity-element.html"><code>&lt;activity&gt;</code></a> element.
This means that if your application issues an
intent to open the Android Browser, its activity is <em>not</em> placed in the same
task as your application. Instead, either a new task starts for the Browser or, if the Browser
already has a task running in the background, that task is brought forward to handle the new
intent.</p>

<p>Regardless of whether an activity starts in a new task or in the same task as the activity that
started it, the <em>Back</em> button always takes the user to the previous activity. However, if you
start an activity that specifies the <code>singleTask</code> launch mode, then if an instance of
that activity exists in a background task, that whole task is brought to the foreground. At this
point, the back stack now includes all activities from the task brought forward, at the top of the
stack. </p>




<p>For more information about using launch modes in the manifest file, see the
<code><a href="../../../guide/topics/manifest/activity-element.html">&lt;activity&gt;</a></code>
element documentation, where the <code>launchMode</code> attribute and the accepted values are
discussed more.</p>

<p class="note"><strong>Note:</strong> The behaviors that you specify for your activity with the <a
href="../../../guide/topics/manifest/activity-element.html#lmode"><code>launchMode</code></a> attribute
can be overridden by flags included with the intent that start your activity, as discussed in the
next section.</p>



<h4 id="#IntentFlagsForTasks">Using Intent flags</h4>

<p>When starting an activity, you can modify the default association of an activity to its task
by including flags in the intent that you deliver to <code><a href="../../../reference/android/app/Activity.html#startActivity(android.content.Intent)">startActivity()</a></code>. The flags you can use to modify the
default behavior are:</p>

<p>
  <dt><code><a href="../../../reference/android/content/Intent.html#FLAG_ACTIVITY_NEW_TASK">FLAG_ACTIVITY_NEW_TASK</a></code></dt>
    <dd>Start the activity in a new task. If a task is already running for the activity you are now
starting, that task is brought to the foreground with its last state restored and the activity
receives the new intent in <code><a href="../../../reference/android/app/Activity.html#onNewIntent(android.content.Intent)">onNewIntent()</a></code>. 
    <p>This produces the same behavior as the <code>"singleTask"</code> <a
href="../../../guide/topics/manifest/activity-element.html#lmode"><code>launchMode</code></a> value,
discussed in the previous section.</p></dd>
  <dt><code><a href="../../../reference/android/content/Intent.html#FLAG_ACTIVITY_SINGLE_TOP">FLAG_ACTIVITY_SINGLE_TOP</a></code></dt>
    <dd>If the activity being started is the current activity (at the top of the back stack), then
the existing instance receives a call to <code><a href="../../../reference/android/app/Activity.html#onNewIntent(android.content.Intent)">onNewIntent()</a></code>,
instead of creating a new instance of the activity.
    <p>This produces the same behavior as the <code>"singleTop"</code> <a
href="../../../guide/topics/manifest/activity-element.html#lmode"><code>launchMode</code></a> value,
discussed in the previous section.</p></dd>
  <dt><code><a href="../../../reference/android/content/Intent.html#FLAG_ACTIVITY_CLEAR_TOP">FLAG_ACTIVITY_CLEAR_TOP</a></code></dt>
    <dd>If the activity being started is already running in the current task, then instead
of launching a new instance of that activity, all of the other activities on top of it are
destroyed and this intent is delivered to the resumed instance of the activity (now on top),
through <code><a href="../../../reference/android/app/Activity.html#onNewIntent(android.content.Intent)">onNewIntent()</a></code>).
    <p>There is no value for the <a
href="../../../guide/topics/manifest/activity-element.html#lmode"><code>launchMode</code></a>
attribute that produces this behavior.</p>
    <p><code>FLAG_ACTIVITY_CLEAR_TOP</code> is most often used in conjunction with <code>FLAG_ACTIVITY_NEW_TASK</code>.  When used together, these flags are a way of locating an existing activity
in another task and putting it in a position where it can respond to the intent. </p>
    <p class="note"><strong>Note:</strong> If the launch mode of the designated activity is <code>"standard"</code>, it too is removed from the stack and a new instance is launched in its place to handle
the incoming intent.  That's because a new instance is always created for a new intent when the
launch mode is <code>"standard"</code>. </p>
</dd>
</dl>





<h3 id="Affinities">Handling affinities</h3>

<p>The <em>affinity</em> indicates which task an activity prefers to belong to. By default, all the
activities from the same application have an affinity for each other. So, by default, all
activities in the same application prefer to be in the same task. However, you can modify
the default affinity for an activity. Activities defined in
different applications can share an affinity, or activities defined in the same application can be
assigned different task affinities.</p>

<p>You can modify the affinity for any given activity with the <a
href="../../../guide/topics/manifest/activity-element.html#aff"><code>taskAffinity</code></a> attribute
of the <a href="../../../guide/topics/manifest/activity-element.html"><code>&lt;activity&gt;</code></a>
element.</p>

<p>The <a
href="../../../guide/topics/manifest/activity-element.html#aff"><code>taskAffinity</code></a>
attribute takes a string value, which must be unique from the default package name
declared in the <a href="../../../guide/topics/manifest/manifest-element.html"><code>&lt;manifest&gt;</code></a> element, because the system uses that name to identify the default task
affinity for the application.</p>

<p>The affinity comes into play in two circumstances:</p>
<ul>
  <li>When the intent that launches an activity contains the <code><a href="../../../reference/android/content/Intent.html#FLAG_ACTIVITY_NEW_TASK">FLAG_ACTIVITY_NEW_TASK</a></code> flag.

<p>A new activity is, by default, launched into the task of the activity
that called <code><a href="../../../reference/android/app/Activity.html#startActivity(android.content.Intent)">startActivity()</a></code>. It's pushed onto the same
back stack as the caller.  However, if the intent passed to <code><a href="../../../reference/android/app/Activity.html#startActivity(android.content.Intent)">startActivity()</a></code> contains the <code><a href="../../../reference/android/content/Intent.html#FLAG_ACTIVITY_NEW_TASK">FLAG_ACTIVITY_NEW_TASK</a></code>
flag, the system looks for a different task to house the new activity. Often, it's a new task. 
However, it doesn't have to be.  If there's already an existing task with the same affinity as the
new activity, the activity is launched into that task.  If not, it begins a new task.</p>

<p>If this flag causes an activity to begin a new task and the user presses the <em>Home</em> button
to leave
it, there must be some way for the user to navigate back to the task. Some entities (such as the
notification manager) always start activities in an external task, never as part of their own, so
they always put <code>FLAG_ACTIVITY_NEW_TASK</code> in the intents they pass to <code><a href="../../../reference/android/app/Activity.html#startActivity(android.content.Intent)">startActivity()</a></code>.  If you have an activity that can be invoked by
an external entity that might use this flag, take care that the user has a independent way to get
back to the task that's started, such as with a launcher icon (the root activity of the task
has a <code><a href="../../../reference/android/content/Intent.html#CATEGORY_LAUNCHER">CATEGORY_LAUNCHER</a></code> intent filter; see the <a
href="#Starting">Starting a task</a> section below).</p>
</li>

  <li>When an activity has its <a
href="../../../guide/topics/manifest/activity-element.html#reparent"><code>allowTaskReparenting</code></a> attribute set to <code>"true"</code>.
  <p>In this case, the activity can move from the task it starts to the task it has an affinity
for, when that task comes to the foreground.</p>
  <p>For example, suppose that an activity that reports weather conditions in selected cities is
defined as part of a travel application.  It has the same affinity as other activities in the same
application (the default application affinity) and it allows re-parenting with this attribute.
When one of your activities starts the weather reporter activity, it initially belongs to the same
task as your activity. However, when the travel application's task comes to the foreground, the
weather reporter activity is reassigned to that task and displayed within it.</p>
</li>
</ul>

<p class="note"><strong>Tip:</strong> If an <code>.apk</code> file contains more than one "application"
from the user's point of view, you probably want to use the <a
href="../../../guide/topics/manifest/activity-element.html#aff"><code>taskAffinity</code></a>
attribute to assign different affinities to the activities associated with each "application".</p>



<h3 id="Clearing">Clearing the back stack</h3>

<p>If the user leaves a task for a long time, the system clears the task of all activities except
the root activity.  When the user returns to the task again, only the root activity is restored.
The system behaves this way, because, after an extended amount of time, users likely have abandoned
what they were doing before and are returning to the task to begin something new. </p>

<p>There are some activity attributes that you can use to modify this behavior: </p>

<dl>
<dt><code><a
href="../../../guide/topics/manifest/activity-element.html#always">alwaysRetainTaskState</a></code>
</dt>
<dd>If this attribute is set to <code>"true"</code> in the root activity of a task,
the default behavior just described does not happen.
The task retains all activities in its stack even after a long period.</dd>

<dt><code><a
href="../../../guide/topics/manifest/activity-element.html#clear">clearTaskOnLaunch</a></code></dt>
<dd>If this attribute is set to <code>"true"</code> in the root activity of a task,
the stack is cleared down to the root activity whenever the user leaves the task
and returns to it.  In other words, it's the opposite of <a
href="../../../guide/topics/manifest/activity-element.html#always"><code>alwaysRetainTaskState</code></a>.  The user always returns to the task in its
initial state, even after a leaving the task for only a moment.</dd>

<dt><code><a
href="../../../guide/topics/manifest/activity-element.html#finish">finishOnTaskLaunch</a></code>
</dt>
<dd>This attribute is like <a
href="../../../guide/topics/manifest/activity-element.html#clear"><code>clearTaskOnLaunch</code></a>,
but it operates on a
single activity, not an entire task.  It can also cause any activity to go
away, including the root activity.  When it's set to <code>"true"</code>, the
activity remains part of the task only for the current session.  If the user
leaves and then returns to the task, it is no longer present.</dd>
</dl>




<h3 id="Starting">Starting a task</h3>

<p>You can set up an activity as the entry point for a task by giving it an intent filter with
<code>"android.intent.action.MAIN"</code> as the specified action and <code>"android.intent.category.LAUNCHER"</code> as the specified category. For example:</p>

<pre>
&lt;activity ... &gt;
    &lt;intent-filter ... &gt;
        &lt;action android:name="android.intent.action.MAIN" /&gt;
        &lt;category android:name="android.intent.category.LAUNCHER" /&gt;
    &lt;/intent-filter&gt;
    ...
&lt;/activity&gt;
</pre>

<p>An intent filter of this kind causes an icon and label for the
activity to be displayed in the application launcher, giving users a way to launch the activity and
to return to the task that it creates any time after it has been launched.
</p>

<p>This second ability is important: Users must be able to leave a task and then come back to it
later using this activity launcher.  For this reason, the two <a href="#LaunchModes">launch
modes</a> that mark activities as always initiating a task, <code>"singleTask"</code> and "<code>"singleInstance"</code>, should be used only when the activity has an <code><a href="../../../reference/android/content/Intent.html#ACTION_MAIN">ACTION_MAIN</a></code>
and a <code><a href="../../../reference/android/content/Intent.html#CATEGORY_LAUNCHER">CATEGORY_LAUNCHER</a></code>
filter. Imagine, for example, what could happen if the filter is missing: An intent launches a
<code>"singleTask"</code> activity, initiating a new task, and the user spends some time working in
that task.  The user then presses the <em>Home</em> button. The task is now sent to the background
and is
not visible. Now the user has no way to return to the task, because it is not represented in the
application launcher.
</p>

<p>For those cases where you don't want the user to be able to return to an activity, set the
  <code><a
href="../../../guide/topics/manifest/activity-element.html">&lt;activity&gt;</a></code> element's
<a href="../../../guide/topics/manifest/activity-element.html#finish"><code>finishOnTaskLaunch</code></a> to <code>"true"</code> (see <a
href="#Clearing">Clearing the stack</a>).</p>



    </div>

  </div> <!-- end jd-content -->
	</article>
	<article class="paging">
		<h1>Wireless  LAN</h1>
         <div >
         	<h2>Architecture</h2>
         	 <div>
         	 	<h3>Stations</h3>
         	 	<p>
         	 	 All components that can connect into a wireless medium in a network are referred to as stations. All stations are equipped with wireless network interface controllers (WNICs). Wireless stations fall into one of two categories: access points, and clients. Access points (APs), normally routers, are base stations for the wireless network. They transmit and receive radio frequencies for wireless enabled devices to communicate with. Wireless clients can be mobile devices such as laptops, personal digital assistants, IP phones and other smartphones, or fixed devices such as desktops and workstations that are equipped with a wireless network interface.
         	 	</p>
         	 </div>
         	 <div>
         	 	<h3>Basic service set</h3>
         	 	<p>
         	 	The basic service set (BSS) is a set of all stations that can communicate with each other. Every BSS has an identification (ID) called the BSSID, which is the MAC address of the access point servicing the BSS.
There are two types of BSS: Independent BSS (also referred to as IBSS), and infrastructure BSS. An independent BSS (IBSS) is an ad-hoc network that contains no access points, which means they can not connect to any other basic service set.
         	 	</p>
         	 </div>
         	 <div>
         	 	<h3>Extended service set</h3>
         	 	<p>
         	 	 An extended service set (ESS) is a set of connected BSSs. Access points in an ESS are connected by a distribution system. Each ESS has an ID called the SSID which is a 32-byte (maximum) character string.
         	 	</p>
         	 </div>
         	 <div>
         	 	<h3>Distribution system</h3>
         	 	<p>
         	 	 A distribution system (DS) connects access points in an extended service set. The concept of a DS can be used to increase network coverage through roaming between cells.
DS can be wired or wireless. Current wireless distribution systems are mostly based on WDS or MESH protocols, though other systems are in use.
         	 	</p>
         	 </div>

         </div><!--  end of architecture -->
         
         <div>
         	<h2>Types of wireless LANs</h2>
         	   <div>
         	 	<h3>Peer-to-peer</h3>
         	 	<p>
         	 	An ad-hoc network is a network where stations communicate only peer to peer (P2P). There is no base and no one gives permission to talk. This is accomplished using the Independent Basic Service Set (IBSS).
A peer-to-peer (P2P) network allows wireless devices to directly communicate with each other. Wireless devices within range of each other can discover and communicate directly without involving central access points. This method is typically used by two computers so that they can connect to each other to form a network.
If a signal strength meter is used in this situation, it may not read the strength accurately and can be misleading, because it registers the strength of the strongest signal, which may be the closest computer.
                 </p>
                 <p>
Hidden node problem: Devices A and C are both communicating with B, but are unaware of each other
IEEE 802.11 defines the physical layer (PHY) and MAC (Media Access Control) layers based on CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance). The 802.11 specification includes provisions designed to minimize collisions, because two mobile units may both be in range of a common access point, but out of range of each other.
The 802.11 has two basic modes of operation: ad hoc mode and infrastructure mode. In ad hoc mode, mobile units transmit directly peer-to-peer. In infrastructure mode, mobile units communicate through an access point that serves as a bridge to a wired network infrastructure. Since wireless communication uses a more open medium for communication in comparison to wired LANs, the 802.11 designers also included shared-key encryption mechanisms: Wired Equivalent Privacy (WEP), Wi-Fi Protected Access (WPA, WPA2), to secure wireless computer networks.
         	 	</p>
         	 </div>
         	   <div>
         	 	<h3>Bridge</h3>
         	 	<p>
         	 	 A bridge can be used to connect networks, typically of different types. A wireless Ethernet bridge allows the connection of devices on a wired Ethernet network to a wireless network. The bridge acts as the connection point to the Wireless LAN.
         	 	</p>
         	 </div>
         	   <div>
         	 	<h3>Wireless distribution system</h3>
         	 	<p>
         	 	A Wireless Distribution System enables the wireless interconnection of access points in an IEEE 802.11 network. It allows a wireless network to be expanded using multiple access points without the need for a wired backbone to link them, as is traditionally required. The notable advantage of WDS over other solutions is that it preserves the MAC addresses of client packets across links between access points.</p><p>
An access point can be either a main, relay or remote base station. A main base station is typically connected to the wired Ethernet. A relay base station relays data between remote base stations, wireless clients or other relay stations to either a main or another relay base station. A remote base station accepts connections from wireless clients and passes them to relay or main stations. Connections between "clients" are made using MAC addresses rather than by specifying IP assignments.</p><p>
All base stations in a Wireless Distribution System must be configured to use the same radio channel, and share WEP keys or WPA keys if they are used. They can be configured to different service set identifiers. WDS also requires that every base station be configured to forward to others in the system.</p><p>
WDS may also be referred to as repeater mode because it appears to bridge and accept wireless clients at the same time (unlike traditional bridging). It should be noted, however, that throughput in this method is halved for all clients connected wirelessly.</p><p>
When it is difficult to connect all of the access points in a network by wires, it is also possible to put up access points as repeaters.
         	 	</p>
         	 </div>
         </div><!--  end Types of wireless LANs -->
         
         <div>
         	<h2>Roaming</h2>
         	<p>There are two definitions for wireless LAN roaming:</p>
         	<ul>
         		<li>
         		 Internal Roaming (1): The Mobile Station (MS) moves from one access point (AP) to another AP within a home network because the signal strength is too weak. An authentication server (RADIUS) presumes the re-authentication of MS via 802.1x (e.g. with PEAP). The billing of QoS is in the home network. A Mobile Station roaming from one access point to another often interrupts the flow of data among the Mobile Station and an application connected to the network. The Mobile Station, for instance, periodically monitors the presence of alternative access points (ones that will provide a better connection). At some point, based on proprietary mechanisms, the Mobile Station decides to re-associate with an access point having a stronger wireless signal. The Mobile Station, however, may lose a connection with an access point before associating with another access point. In order to provide reliable connections with applications, 
         		 the Mobile Station must generally include software that provides session persistence.
         		</li>
         		<li>
         		 External Roaming (2): The MS (client) moves into a WLAN of another Wireless Internet Service Provider (WISP) and takes their services (Hotspot). The user can independently of his home network use another foreign network, if this is open for visitors. There must be special authentication and billing systems for mobile services in a foreign network.

         		</li>
         	</ul>
         </div>
	</article><!--  end of wireless lan -->

</body>
</html>
